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Response dated Apr. 25, 2006 

Reply to Office Action of Jan. 25, 2006 



REMARKS/ARGUMENTS 



Claims 1-5, 9, 14, 15, 17 and 18 remain In the application, all of which 
stand rejected. Although the Examiner's "Office Action Summary" refers to 
claims 1-5, 9 and 14-18, claim 16 was canceled in a prior Amendment. 



1. Reiection of Claims 1, 3. 4, 5 and 9 Under 35 USC SI 02(e) 

Claims 1, 3, 4, 5 and 9 stand rejected under 35 U.S.C. 102(e) as being 
anticipated by U.S. Pat. No. 6,871,233 to Bearden et al. (hereinafter, "Bearden"). 
Claim 1 recites: 

An apparatus for identifying a requested level of service for a 

transaction, comprising: 

computer readable storage media; and 

computer readable program code stored in said storage 

media, comprising: 

a) program code for prompting a user to select a 
requested level of service for said transaction; and 

b) program code for assigning said requested level of 
service to said transaction. 

Claim 5 recites: 

An apparatus for identifying a requested level of service for a 

transaction, comprising: 

computer readable storage media; and 

computer readable program code stored in said storage 

media, comprising: 

a) program code for selecting said requested level of 
service for said transaction, said requested level of service 
being based on a user identification; and 

b) program code for assigning said requested level of 
service to said transaction. 
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In rejecting claims 1 and 5, the Examiner asserts that: 



Bearden teaches the invention as claimed including method 
and apparatus for use in specifying and insuring service-level 
quality of service in computer networks (see abstract). 

As to claims 1 and 5. Bearden teaches an apparatus for 
identifying a requested level of service for a transaction, 
comprising: 

computer readable storage media (figure 3, item 302); and 
computer readable program code stored in said storage media, 
comprising: 

a) a program code for prompting a user to select a 
requested level of service for said transaction, said requested 
level of service being based on a user identification (column 1 , 
lines 54-67; column 4. lines 20-25); 

b) program code for assigning said requested level of 
service to said transaction (column 2, lines 3-7). 

1/25/2006 Office Action, p. 3, sec. 3 (emphasis added). 

Applicants disagree. Of note, neither of applicants' claims 1 or 5 contains 
the limitation a) that is referenced by the Examiner in the above excerpt. It 
appears that the Examiner has formed this limitation by combining the limitations 
a) found in applicants' claims 1 and 5. However, the Examiner's above limitation 
a) is not found in either of applicants' claims. It is therefore believed that the 
Examiner's rejection of claims 1 and 5 is improper, does not set forth a prima 
facie basis for rejecting these claims, and should be withdrawn. 

Regardless of the above deficiency in the Examiner's rejection, and in the 
interest of pursing a rapid conclusion to prosecution, applicants note that 1) with 
respect to claim 1, Bearden fails to show "a) program code for prompting a user 
to select a requested level of service for said transaction...", and 2) with respect 
to claim 5, Bearden fails to show "a) program code for selecting said requested 
level of service for said transaction, said requested level of service being based 
on a user identification...". 
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Bearden teaches how a user, such as an administrator, can: 

...specify parameters for predefined types of service level QoS 
goals. A QoS goal is defined by specifying a client, a service and a 
QoS expression. A QoS expression is a proposition that indicates 
the client's desired range of values for some QoS metric, e.g., 
service response time or service availability. 

Bearden col. 1, lines 56-61. 

As shown in Bearden's FIG. 4, and specifically in decision boxes 411 and 
412, and in steps 417 and 418, Bearden's QoS goals cause the network 
resources assigned to a particular client to be increased or decreased based on 
whether a QoS goal was met (or not) for past transactions. Thus, the client is not 
prompted to "select a requested level of service" for any particular transaction, 
but is only prompted to specify a QoS goal for all transactions. The QoS goal is 
then enforced by a management server 301 (FIG. 3) which automatically 
allocates and de-allocates network resources to increase or decrease the QoS 
given to a current transaction, in response to the QoSs that were actually 
provided to past transactions. An overall QoS goal for a group of transactions is 
thereby maintained. If a user wants to request a particular level of service for 
any particular transaction, it appears that Bearden offers no way to do this. Nor 
does Bearden provide any way to select a "requested level of service for [a] 
^ transaction. . .based on a user identification" (as recited in claim 5). 

Claims 1 and 5 are believed to be allowable for at least the above 
reasons. 

With respect to claim 3, the Examiner asserts that Bearden teaches 
"program code for selecting a backup level of service" in FIG. 4, and in col. 5, line 
45 - col. 6, line 24. Applicants disagree. The Examiner's cites only refer to 
allocating and de-allocating network resources to achieve a single QoS goal (or 
set of goals). Applicants cannot find any mention of anything corresponding to a 
"backup level of service". Claim 3 is therefore believed to be allowable because 
it depends from claim 1 , and for other reasons. 
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Claim 4 is believed to be allowable at least for the reason that it depends 
from claim 1. Claim 9 is believed to be allowable at least for reasons similar to 
why claim 1 is believed to be allowable. 



2. Reiection of Claims 14. 15. 17 and 19 Under 35 (JSC S102fe) 

Claims 14, 15, 17, and 19 stand rejected under 35 U.S.C. 102(e) as being 
anticipated by U.S. Pat. No. 6.483,805 to Davies et al. (hereinafter, "Davies"). 
Claim 14 recites: 

An apparatus for routing a transaction over a networl^ based 
on a requested level of service associated with said transaction, 
comprising: 

a number of computer readable storage media; and 
computer readable program code stored in said number of 
storage media, comprising: 

a) program code for selecting said requested 
level of service for said transaction; 

b) program code for assigning a service tag to 
said transaction, said service tag including said requested 
level of service, and said program code assigning parts of 
said service tag at more than one point on said network; 

c) program code for reading said requested level 
of service from said service tag; and 

d) program code for directing said transaction 
over said network based on said requested level of service 
read from said service tag. 

The examiner states, "a) program code for selecting said requested level 
of service for said transaction [is taught by Davies at] column 7, lines 47-59..." 
(see, 1/25/2006 Office Action, p. 5, §a). Applicants disagree. Davies states: 

Because of the nature of the packet traffic generated by an 
application requiring a transactional service (for example web page 
request and download) it is difficult to create such a Service Level 



Page 6 of 9 



Appl. No. 09/751,009 

Response dated Apr. 25, 2006 

Reply to Office Action of Jan. 25, 2006 

Agreement based on a single class for such packets. The network 
is unable to predict or readily control the load imposed by traffic of 
this nature. 

Davies, column 7, lines 47-59. 

Applicants fail to appreciate the relevance of the cited reference and find 
no teaching or suggestion of the claimed limitation. Ignoring for the moment that 
the reference routes packets, as opposed to directing transactions, the reference 
appears to be teaching away from the Applicant's claim 14. While Davies finds it 
"difficult to create" a single class of packets for a transaction for predicting and 
controlling the load of such packets, claim 14 selects level of service for a 
transaction, assigns a service tag to a transaction, and then directs the 
transaction accordingly. 

The examiner also asserts that: 

b) program code for assigning a service tag to said 
transaction, said service tag includes said requested level of 
service, and said program code assigning parts of said service tag 
at more than one point on said network [is taught by Davies at] 
column 6, line 66 to column 7, line 6 [and] column 8, line 62 to 
column 9, line 4... 

1/25/2006 Office Action, p. 5. §b. 

Applicants disagree. Davies teaches, "...marking each individual packet 
used to deliver data across an IP network with a code comprising a small number 
of bits. (Davies, col. 6, line 66 - col. 7, line 6). Applicants' claim 14 recites, 
"assigning a service tag to [a] transaction". 

Davies at column 8, line 62 to column 9, line 4 discusses the throttling of 
the data flow sent by a TCP source via a windowing mechanism. Applicants fail 
to appreciate the relevance of the reference and find no teaching or suggestion 
of the claimed limitation. 



Page 6 of 9 



Appl. No. 09/751,009 

Response dated Apr. 25, 2006 

Reply to Office Action of Jan. 25, 2006 



The examiner then asserts that: 

c) reading said requested level of service from said service; 
and d) directing said transaction over said network based on said 
requested level of service read from said service tag [is taught by 
Davies at] column 7, lines 34-45. 

1/25/2006 Office Action, p. 5, §c. 

Applicants disagree. What Davies teaches is: 

Routers which process the packets as they are forwarded 
across the IP network inspect the code and treat each packet 
marked with the same value in the same way when determining the 
priority or preference to give to those packets on the next hop of 
their path through the network. Each set of similarly-marked 
packets constitutes an [sic] class, and by applying different 
treatments to different classes a different quality of service 
can be obtained for each class. For example, access to a portion 
of the network may be refused to traffic in a given class which 
exceeds, in some measurable way, a previously agreed contract 
typically known Service Level Agreement (SLA). 

Davies, column 7, lines 34-45. 



Applicants' claim 14 teaches the reading of a level of service from a 
transaction's service tag and directing the transaction accordingly, whereas 
Davies routes packets. Davies' purpose for placing "a small number of bits" on 
a packet is to lump certain "bits" into classes. The classes are then subject to 
class-specific routing. Routing is the passive execution of processes to allow a 
packet to reach its intended destination. Directing, as in claim 14, actively 
determines where the transaction is to go. 

For at least the above reasons, claim 14 is believed to be allowable. 
Claims 15, 17, and 18 are believed allowable for at least the reason that they 
depend from claim 14. 
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3. Rejection of Claim 2 Under 35 USC S1 03(a) 

Claim 2, althougli not specifically mentioned in the Examiner's rejection, 
appears to stand rejected under 35 U.S.C. 103(a) as being unpatentable over 
U.S. Pat. No. 6,871,233 to Bearden et al. (hereinafter. "Bearden") in view of U.S. 
Pat. No. 6,483,805 to Davies et al. (hereinafter, "Davies"). 

Applicants believe claim 2 is allowable, at least, for the reason that it 
depends from claim 1 , which is believed to be allowable over Bearden. See, 
Section 1 of these Remarks/Arguments, supra. Davies fails to teach what is 
missing from Bearden. 

Furthermore, the references lack any suggestion to be combined, and 
such a combination would be counterintuitive. Davies teaches the routing of 
packets (Davies, abstract). It is known in the art that packets may be a portion of 
data or a transaction. A solution that is indifferent to a packet's content, that is, if 
the packet is a transaction, a portion of a transaction, or, for example, a video 
file, is unlikely to be considered a viable solution to transaction routing. Davies 
also views the problem of managing individual flows of packets, let alone 
individual packets, as an impossibility. 

To avoid problems of scalability in the core of large 
networks, where there are many hundreds or thousands or millions 
of flows of packets, the QoS cannot be specified at the 
granularity of individual flows in the core of the network. The 
treatment of packets in the core of the network to achieve the 
desired QoS must be very simple: there is very little time and 
processing effort available for each packet in a network core device 
in which a new packet may be arriving as frequently as every 50- 
100 ns. 

Davies, p. 6, lines 41-49. 

For at least the above reasons, claim 2 is believed to be allowable. 
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4. Conclusion 

In summary, the art of record does not teach nor suggest the subject 
matter of applicants' claims 1-5, 9, 14, 15, 17 and 18. These claims are therefore 
believed to be allowable, and accordingly, applicants respectfully request the 
issuance of a Notice of Allowance. 



Respectfully submitted, 
DAHL & OSTERLOTH, L.L.P. 




Gregory W. Osterloth 
Reg. No. 36, 232 
Tel: (303) 291-3204 
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